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«Proced6 de replication d'une application logicielle dans une 
architecture multi-ordinateurs, precede pour r^aliser une 
continuity de f onctionnement mettant en oeuvre ce procSdS de 
5 replication, et systdme multi-ordinateurs ainsi 6quip6 » 



La prgsente invention conceme un procSd^ pour r^pliquer 
une application logicielle dans une architecture multi- 

10 ordinateurs (cluster) . Elle vise egalement un precede pour 
realiser une continuite de f onctionnement d'une application 
logicielle au sein d'un cluster d' ordinateurs, qui met en 
(Euvre le proced6 de replication selon 1 ' invention, ainsi 
qu'un systdme multi-ordinateurs impl^mentant ce precede de 

15 continuity de f onctionnement • 

Le domaine de 1' invention est celui des clusters 
d • ordinateurs formes de plusieurs ordinateurs collaborant 
entre eux. Ces clusters sont par exemple pr^vus pour ex6cuter 
des applications logicielles. Ainsi, k xm instant dozing, \ine 

20 application est execut^e sur I'un des ordinateurs du cluster, 
appeie ncEud primaire ou opSrationnel (OP) , tandis que les 
autres ordinateurs du cluster sont appelSs noeuds secohdaires 
ou <c stand-by » (SB) , dans un contexte d* architecture 
redondante . 

25 Or, 1 ' exploitation de tels clusters montre que se posent 

des problemes de f lability qui peuvent Stre dus k des 
def alliances du materiel ou du systeme d' exploitation, a des 
erreurs humaines, ou k la d^f alliance des applications elles- 
memes . 

3 0 Pour rgsoudre ces problSmes de fiabilite, il existe 

actuellement des mgcanismes, dits de haute disponibility , qui 
sont mis en oeuvre sur la plupart des clusters actuels et qui 
sont bas^s sur un red^marrage automat ique froid de 
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1* application sur un nceud de secours parmi I'un des noeuds 
secondaires du cluster. 

Or ces m^canismes bases sur un redemarrage automatique 
ne permettent pas d' assurer une continuite totale du services 
5 fourni par 1 ' application en cours d' execution au moment de Ca 
def alliance. 

En particulier, se pose le probleme de la replication 
d'une application logicielle au sein d'une architecture 
multi-ordinateurs^ cette replication devant assurer une 
10 continuite totale de service. 

Un object if principal de la pr6sente invention est done 
de proposer un procede pour repliquer une application 
logicielle dans une architecture multi-ordinateurs (cluster) , 
ladite application logicielle 6tant pr6alablement ex6cutee 
15 sur un premier ordinateur dudit cluster constituant un noeud 
primaire et etant destin^e k Stre r6pliqu6e sur au moins un 
autre ordinateur dudit cluster constituant un noeud 
secondaire^ comprenant une replication des ressources 
associ^es ^ ladite application logicielle. 
20 Get objectif principal est atteint avec un tel procede 

de replication caract6rise en ce qu'il comprend une mise k 
jour au fil de I'eau des ressources r6pliqu6es par un 
m6canisme d' introspection dynamique pr6vu pour fournir la 
structure de 1' application a repliquer,. ainsi que le graphe 
25 dynamique des ressources et dependances mises en oeuvre. 

On peut en outre avantageusement pr^voir que ce proc6de 
de replication comprenne en outre une creation et une 
. maintenance d'un arbre de d^pendance, qui fournit a chaque 
instant des informations sur les ressources qu'il est 
30 n6cessaire de r6pliquer. 

II est important de noter que dans le proced6 de 
replication selon 1' invention, le nombre de noeuds secondaires 
ou stand-by concern6s peut §tre quelconque. 
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Dans un mode de realisation pref6r§ de 1' invention, le 
procede de replication selon 1' invention comprend en outre un 
mecanisme dit de « point de reprise (« checkpointing ») par 
lequel les ressources a repliquer sont repliqu6es sur un ou 
5 plusieurs noeuds secondaires. 

Le procede de replication selon 1' invention peut 
avantageusement comprendre les trois etapes suivantes: 

- capture des ressources sur le noeud primaire, 

- transfert par le r6seau vers un ou plusieurs noeuds 
10 secondaires, 

- restauration sur le ou les noeuds secondaires. 

Le precede de replication selon 1' invention peut etre 
avantageusement mis en oeuvre pour une optimisation 
automatique de ressources informatiques par partage de charge 
15 par repartition dynamique de processus. II peut aussi §tre 
utilise pour une maintenance non interruptive par relocation 
a la demande de processus au travers d'un reseau de 
ressources informatiques, ou pour une preservation de 
contexte applicatif dans des applications mobiles. 
20 Un autre but de la presente invention est de proposer un 

procede pour realiser une continuite de f onctionnement d'une 
application logicielle dans une architecture multi- 
ordinateurs (cluster) , cette application etant executee a un 
instant donne sur I'un des ordinateurs du cluster, appeie 
25 noeud principal ou operationnel, les autres ordinateurs dudit 
cluster etant appeies noeuds secondaires. 

Cet autre objectif est atteint avec un precede pour 
realiser une continuite de f onctionnement d'une application 
logicielle dans une architecture multi-ordinateurs (cluster) , 
30 cette application etant executee a un instant donne sur I'un 
des ordinateurs du cluster, appeie noeud principal, les autres 
ordinateurs dudit cluster etant appel6s noeuds secondaires. 
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Suivant l^inventiorir le proc6d6 comprend les etapes 
suivantes : 

- replication de 1' application sur au moins des nceuds 

secondaires, de fagon a r^aliser au moins un clone de 
5 ladite application^ 

- mise a jour au fil de I'eau dudit ou desdits clones, et 

- en cas de detection d'une def alliance ou d'un evenement 

affectant ledit . ncEud principal, basculement de service 
vers I'un au moins desdits clones. 
10 Ainsir avec le proc6d6 de realisation de continuite de 

fonctionnement selon 1' invention, il est d6sormais possible 
de disposer de noeuds secondaires pourvus de clones 
d' application resultant de la replication de 1' application et 
aptes a relayer sans discontinuity cette application en cas 
15 de detection de d6f alliance ou d*ev6nement affectant le nceud 
principal • 

La replication mise en oeuvre dans le precede de 
replication selon 1' invention est avantageusement de type 
holistique. On dispose ainsi d'un clonage de 1 ' application au 
20 fil de I'eau, avec une mise a jour de ces clones, de fagon 
deterministe et complete. 

Ces clones sont dits « chauds », c'est-^-dire qu'ils 
sent la replique exacte de 1 ' application et de tout son 
contexte operatoire. lis sont mis a jour regulierement 
25 (periodiquement ou sur evenement s caracteristiques) . Ces 
clones contiennent toutes les res sources et informations 
requises par 1 • application pour fournir son service. 

Le precede de replication selon 1' invention permet en 
outre de superviser I'etat de toutes les ressources 
30 necessaires au bon fonctionnement de 1 ' application, Quand la 
degradation redhibitoire de I'une d'entre elles est detectee, 
le precede de replication selon 1' invention prevoit une 
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election d'un clone coratne nouveau primaire et lui ordonne de 
prendre la main. 

Cette election est appel§e basculement et est 
transparente pour le reste du monde qui communique avec 
5 1 ' application : bien que le noeud primaire soit mis hors 
service, le service fourni par 1' application n'est pas 
interrompu car il est repris avec tout son contexte par le 
clone elu. 

On peut ainsi garantir que tout message transmis par le 
10 reste du monde a 1 ' application sera traite^ soit par le noeud 
primaire (pre-basculement) , soit par le clone (post- 
basculement) • Pour ce faire, le proc6d6 de replication selon 
1* invention peut en outre comporter un enregistrement sur 
chaque clone (en plus du mecanisme de clonage periodique) de 
15 tous les messages regus par le primaire depuis la derni^re 
mis k jour des clones. Ces messages seront reinject6s dans le 
clone 61u nouveau primaire en cas de basculement. 

La replication holistique reprend des mecanismes deja 
mis en oeuvre dans des syst%mes existants de migration de 
20 process. Cependant, la conception et 1 'utilisation qui en 
sont faites dans le proc6de de replication selon 1' invention 
different de tous les travaux ant6rieurs connus. 

Le proc6d6 de realisation de continuity de 
f onctionnement selon 1' invention met ainsi en ceuvre une 
25 replication transparente^ holistique et optimisee, dediee a 
la continuite de service par delocalisation de 1' application 
et virtualisation des ressources. 

Avec ce proc6d6, on resout plusieurs limitations de§ 
implementations classiques qui les rendaient inoperantes pour 
30 une utilisation en tolerance aux pannes au sein d'une 
architecture multi-ordinateurs en cluster. 

Une premiere limitation r6sidait dans le probleme de 
1 ' ind^pendance entre noeud primaire et noeud secondaire. Dans 
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les systfemes clas'siques, la r6plication d'une ressource d'un 
ncBud primaire vers un noeud secondaire presuppose et n6cessite 
la presence op6rationnelle du noeud primaire pendant tout le 
precede* Le proc§d§ de replication selon 1' invention resout 
5 cette limitation, puisque le clone peut a tout instant vivre 
de fagon autonome meme en cas de disparition du primaire- 
Cette de-corr61ation primaire / secondaire est un pr6 requis 
pour la tolerance aux pannes • 

Comme la replication implement^e dans le procede de 
10 replication selon 1' invention est holistique, on capture 
1' integrality coh6rente de ressources asynchrones 
interd6pendantes* Dans les proc6des de I'art ant^rieur, seuls 
etaient captures les etats de ressources ind^pendantes . 

Une autre limitation des proc6des de I'art ant6rieur 
15 rfesidait dans le probl^me de 1' intrusivit^. Le proc6d6 de 
replication selon 1' invention est non intrusif sur le code 
source : les instances ant6rieures necessitent de modifier le 
code source (ou de le concevoir explicitement) pour que les 
processus inf ormatiques cr66s et les ressources utilisees 
20 puissent Stre migres. 

II est a noter que pour la mise en ceuvre du proced6 de 
replication selon 1' invention, on peut avantageusement 
utiliser des techniques d'ingenierie logicielle non intrusive 
dynamique, qui ont fait I'objet d'une demande de brevet 
25 publi6e le 2 aoCit 2002 sous le num^ro FR2820221. Ces 
techniques d'ingenierie logicielle permettent de manipuler 
des applications dans leur representation binaire 
(executable) , de f agon a rendre le precede de realisation de 
continuite de f onctionnement selon 1' invention transparent 
30 pour 1 * application et done generique. 

Suivant un autre aspect de 1' invention, il est 
propose un systeme multi-ordinateurs prevu pour executer sur 
au moins des ordinateurs au moins une application logicielle. 
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implement ant le proced6 pour r6aliser une continuity de 
fonctionnement selon 1' invention. 

D'autres avantages et caracteristiques de 1' invention 
apparaltront k I'examen de la description d6taillee d'un mode 
5 de mise en oeuvre nullement limitatif , et des dessins annexes 
sur lesquels : 

-la figure 1 illustre la fonction de miroir dynamique mise 
en oeuvre dans le precede de replication selon 
1 ' invention ; 

10 -la figure 2 illustre schematiquement les principes de 

r6plication de donn6es mis en oeuvre dans le proc6d6 de 
replication selon 1* invention ; 
-la figure 3 repr6sente un exemple d' architecture 
logicielle mettant en oeuvre le proc6de de replication 
15 selon 1' invention, pour la supervision et la detection 

de d6faillance ; 
-la figure 4 illustre schematiquement des principes de 
supervision mis en oeuvre dans le precede de replication 
selon 1 ' invention ; 
20 -la figure 5 illustre schematiquement le mecanisme de 

copie sur ecriture (« copy on write ») mis en oeuvre dans 
le precede de replication selon 1' invention ; 
-la figure 6 illustre schematiquement le mecanisme 
d' incrementation pour replication mis en oeuvre dans le 
25 precede de replication selon 1' invention ; et 

-la figure 7 illustre schematiquement le mecanisme de 
commutation mis en oeuvre dans le precede de replication 
selon 1 ' invention . 

On va d'abord deer ire, en reference aux figures 
30 precitees, le fonctionnement du mecanisme de replication 
holistique mis en oeuvre dans le precede de replication selon 
1 ' invention. 
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Pour que 1' application puisse correctement tourner sur 
un noeud secondaire dans le cas d'un basculement, il est 
necessaire que 1" ensemble des ressources requises par cette 
application soit egalement r6pliqu6 sur le noeud secondaire* 
5 Si ces ressources sont des ressources ^ etat^ i.e. 

qu'elles varient au fil de 1' execution de 1' application et 
contribuent a son contexte global, alors leur 6tat doit 
egalement etre capture et replique de faq:on coherente. 

L' ensemble de ces ressources est decouvert a 
10 1' initialisation de 1 ' application puis maintenu a jour au fil 
de I'eau par des mecanismes d' introspection dynamique qui 
permettent d'obtenir automat iquement la structure de 
1' application a proteger, ainsi que le graphe dynamique des 
ressources et d6pendances mises en ceuvre. 
15 Ces m6canismes s'appuient sur les caracteristiques 

reflexives des binaires, sur les mfecanismes d' heritage des 
syst^mes d' exploitation et sur la surveillance, via une 
instrvimentation binaire, des mecanismes - incluant les appels 
syst6me - qui contribuent modifier l'6tat de ses 

20 ressources. 

En reference k la figure 4, dans un exemple de mise en 
ceuvre du precede de replication selon 1' invention, des 
pilotes (drivers) d' introspection et de surveillance assurent 
une surveillance sur tous les noeuds du cluster et 
25 transmettrent des donnees de surveillances a la base 
d' information de gestion MIB du systeme. Cette base MIB est 
sollicitee a la fois dans la gestion du cluster sur le noeud 
op6rationnel pour les declenchements de point de reprise 
(checkpoint) et dans la gestion du cluster sur des noeuds 
30 « back-up ». La base MIB est 6galement sollicitee par le 
gestionnaire de supervision avec une base MIB synthfetique et 
est accedee par 1' administrateur systeme auquel sont 
associees des interfaces utilisateur graphiques (GUI) . 
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Le resultat de ce travail de decouverte et 
d' introspection au fil de I'eau est la creation et la 
maintenance d'un « arbre de d6pendance qui fournit au 
proc6d§ de r§plication selon 1' invention a chaque instant des 
5 informations sur les ressources qu'il est n^cessaire de 
repliquer. L' existence de ce graphe garantit la completude et 
la coherence des clones. 

On autre mecanisme de point de reprise 
(« checkpointing ») , mis en oeuvre dans le precede de 
10 realisation de continuite de f onctionnement selon 
1' invention, consiste a repliquer les ressources sur un ou 
plusieurs noeuds secondaires. Ce mecanisme de replication des 
ressources est realise en trois 6tapes : 

- capture des ressources sur le noeud primaire, 

15 - transfert par le reseau vers un ou plusieurs nceuds 

secondaires, et 

- restauration sur le ou les noeuds secondaires • 
Les ressources r6pliqu6es incluent : 

- la memoire virtuelle de chaque processus concern6 
20 ainsi que sa pile d'appel, 

- des ressources systemes (inter process communication, 
connexion reseau, etc.)/ Bt 

- des donnees ecrites sur disques. 

Le mecanisme de replication des ressources assure que 
25 1' ensemble des ressources n^cessaires a 1 ' application est 
transfere de fagon complete et coherente (d'ou holistique) . 

La mise en oeuvre du proc6de de replication selon 
1' invention garantit que 1 ' application puisse continuer de 
vivre sur le secondaire sans perdre son contexte : 
30 1 • application est d61ocalis6e, le materiel et le systfeme 
d' exploitation sous-jacent sont virtualises, 1' application se 
comportant ind6pendamment de sa localisation physique. 
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En cas de basculement, 1' application, n'est pas 
consideree coinme stoppee : elle continue de tourner dans son 
context e^ mais sur d' autre ressources materielles . 

Les ressources mises en oeuvre par 1 ' application sont 
5 diverses et variees (multi process, syst^me d' exploitation , 
etc.)- Elle vivent de fagon asynchrone, sur un environnement 
non deterministe, 

Le proc6d6 de replication selon 1' invention met en oeuvre 
un algorithme de « checkpointing » (generation de points de 
10 reprise) asynchrone : une barriere de synchronisation est 
transmise a toutes les ressources et le procede de 
replication selon 1' invention garantit que la capture d^etat 
est complete et coherente- 

On va maintenant decrire une technique d' optimisation 
15 raise en oeuvre dans le precede de replication selon 
1* invention. La capture deterministe et complete de l'6tat de 
toutes les ressources est coOteuse pour les performances du 
systeme. Or, un faible impact sur les performances de 
1' application est un pr6 requis pour 1 ' acceptabilit6 par le 
20 march6 du produit et done in fine pour son utility. Plusieurs 
techniques d' optimisation ont done et6 congues et developp6es 
pour rainimiser cet impact. 

Premi^rement, le point de reprise quasi synchrone est 
une optimisation des m6canismes de generation de point de 
25 reprise (checkpointing) classiques : il offre la coherence de 
capture des algorithmes synchrones, sans pour autant 
n§cessiter 1' arret total du systeme pendant la capture que 
n6cessit^nt les algorithmes asynchrones. 

La p6riode du point de reprise est ajustable, de sorte ^ 
30 optimiser le compromis entre le temps de reprise apres 
basculement (potent iellement d' autant plus long que la 
p6riode entre deux points de reprise est longue) et la 
quantity d' information d'6tat a capturer et ^ transferer. 




wo 2004/015574 PCT/FR2003/002371 

Par ailleurs, le point de reprise est incremental : 
seules les differences d'etat entre deux points de reprise 
sont transmises, coinme I'illustre I'exemple fonctionnel de la 
figure 1. Dans cet exemple, un point de reprise incr6mental 
5 est effectu6 k partir de 1' application maltre pour obtenir 
1' application replique et un disque partage entre les deux 
noBuds primaire et secondaire est mis en cEUvre^ 

Ainsi, le premier point de reprise est cher en 
performance (initialisation des clones) mais les suivants 
10 sont d' impact faible* 

Le point de reprise est egalement discriminant : 
1' analyse intelligente du graphe de dependance permet de 
limiter au strict necessaire la quantity d' information a 
transmettre . 

15 Enfin, des m^canismes de « Copy On Write » (copie sur 

ecriture) offerts par le systeme d' exploitation sont mis en 
ceuvre pour s6parer le temps de capture du temps de transfert, 
en reference a la figure 5 qui illustre un exemple de mise en 
ceuvre d'un m^canisme de copie sur ecriture dans un proc6d6 de 
20 replication selon I'invention, k la suite du d§clenchement 
d'un point de reprise. Dans cet exemple ^ le mfecanisme de 
copie sur Ecriture intervient sur des blocs de donn6es 
(m6moire ou disque) pour une nouvelle r^f^rence^ apres une 
requete en 6criture issue d'un Utilisateur via un process ou 
25 un i-node (noeud d' index) • Seuls les blocs de donnfees modifies 
sont r^pliques, comme 1' illustre la figure 6. 

On va maintenant d6crire un exemple de mise en ceuvre du 
mecanisme de generation de point de reprise quasi-synchrone 
au sein du proc^de de realisation de continuite de 
30 fonctionnement selon 1' invention. Ce mecanisme inclut : 

- une barriere de synchronisation de processus (« Process 
Synchronisation Barrier » : PSB) , 
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- une gestion de ressources {« Ressource Management » : 

RM), 

- une gestion de ressources systeme {« System Resources 

Management » : (SRM) , et 
5 - une gestion de ressources de processus {« Process 

Resources Management » (PRM) . 

La barriers de synchronisation de processus (FSB) est un 
mecanisme permettant de synchroniser le blocage des processus 
composant une application tout en respectant la gestion des 
10 entrees/sorties en cours^ dans le but de pouvoir prendre a un 
instant T une "photographie" non floue de I'etat du systeme 
et de I'application, 

La gestion de ressources (RM) est un ensemble 
d' automates gen6riques permettant de mettre en oeuvre le 
15 s6quencement des differentes phases du checkpointing vis a 
vis des differentes ressources n6cessaires pour repliquer une 
application d'une machine sur une autre: 

La gestion de ressources systeme (SRM) inclut des 
m6canismes permettant de gerer les differentes routines de 
20 gestion des ressources syst^mes utilisfees par une application 
(ensemble de processus) lors des differentes phases du 
mecanisme de generation de point de reprise. 

La gestion de ressources de processus (PRM) inclut des 
mecanismes permettant de gerer les differentes routines de 
25 gestion des ressources utilisees par un processus lors des 
differentes phases du mecanisme de generation de point de* 
reprise. Ce code est charge dynamiquement a I'interieur des 
processus applicatifs lors de leur lancement. 

II existe aujourd'hui trois phases principales qui sont 
30 elles m§me decoupees en differentes phases necessaires pour 
la captures des ressources utilisees par 1 ' application. 
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La raison d'etre de ces differentes sous-phases est de 
minimiser les temps de blocages applicatif lies a la 
recuperation/restauration des differentes ressources 
applicatives et systeme ainsi que de garantir la coherence 
5 des informations sauvegard^es . 
DUMP: 
RM_PRE_DUMP 
RM_DUMP 
RM_POST_DUMP 
10 RM_ABORT_DUMP 
RESTORE : 
RM_PRE_RESTORE , 
RM__RESTORE, 
RM_POST_RESTORE , 
1 5 RM_ABORT_RESTORE , 

SWITCH: 
RM_PRE_SWITCH, 
RM_S WITCH, 
RM_POST_S WITCH , 
20 RM ABORT SWITCH, 



On va maintenant d6crire une virtualisation des 
ressources syst^mes dans le cadre du precede de replication 
selon 1' invention. Certaines ressources systSmes UNIX sont 

25 caracteris6es par un identifiant unique propre k chaque 
machine. Ces identifiants sont stockes sous forme de 
variables par les applications, ce qui leur permet de pouvoir 
les referencer. Lors de la migration d'une application d'une 
machine a une autre la memoire des applications est 

30 integralement transferee, y compris les donn6es relatives aux 
ressources systemes. Pour pouvoir garantir I'unicite du 
r6f erencement des ressources systeme par une application 
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META-CLUSTER met en oeuvre des mecanismes de virtualisation 
de ces ressources^ permettant de maintenir des identifiants 
uniques entre les differentes machines composant un CLUSTER, 
Ces mecanismes de virtualisation sont aujourd'hui 
5 appliques pour les identifiants de ressources systeme 
suivants : 

- Processus 

- PIPE 

- FIFO 

10 - IPC System V 

- Memoires partag§es 

- Semaphores 

- Message queues 

- Socket AF UNIX 
15 - Threads 

Les mecanismes de virtualisation assurent done I'unicite 
du ref6rencement d'une ressource systeme au sein du cluster 
ainsi que sa translation vers une ressource systeme sur 
chaque machine. lis sont implementes sous la forme de modules 
20 noyau dynamiques assurant la non-preemptivit6 de requ§tes qui 
leurs sont faites, sur des systfemes mono et multiprocesseurs^ 
et avec une capacity ^ instrospecter les differentes routines 
permettant de manipuler ces identifiants. 

A titre d'exemple non limitatif, une routine getpld est 
25 instrumentee par META lors de la prise en charge de 
1 ' application par META-CLUSTER et son utilisation par 
1' application retourne un CLUSTER_PID qui pourra ensuite §tre 
utilise par 1' application sur toute routine prenant un PID 
comme parametres (kill, waitpid^ . . . ) • 
30 Le procede de replication selon 1' invention inclut aussi 

un module de replication de fichiers de donnees applicatives 
entre le noeud op6rationnel et le noeud stand-by, d6sign6 sous 
le terme de CFOR (Cluster File system Optimized Replication : 
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Replication Optimisee de systeme de Fichier pour Cluster) , en 
en reference a la figure 2. 

Le module CFOR realise ainsi les fonctions suivantes : 
a) ecriture de donn6es 
5 b) modification du Log (journal) 

c) ordre de replication 

d) synthese construite ^ partir des donnees 

e) synthese de transfert 

f) mise ^ jour du systeme de fichier s (FS) 

10 Le fonctionnement de ce module de replication est le 

suivant : entre chaque copie (dump) , CFOR construit k la 
vol6e un journal cumulatif et synthetique des modifications 
apport^es au systeme de fichiers par les applications 
controlees par le cluster. 
15 Les modifications du systeme de fichier sont extraites a 

la voiee par instrumentation dans les processus applicatifs 
des divers appels systemes: write (2)^ mkdir(2)r rmdir(2), 
unlink (2).. • Le principe consiste ^ ne mSmoriser que les 
actions sans les donnees. Ainsi si une application 6crit 2Mo 
20 dans un fichier^ on ne memorise que 1' action "fichier, 
ecriture, d6but, . fin", les 2Mo de donnees ayant ete 
sauvegardes par I'OS sur le disque, il n'est pas n6cessaire 
de les dupliquer ailleurs. 

Les 6critures multiples sont synthetis6es au fil de 
25 I'eau. Si une application effectue les actions suivantes: 
l.ouverture du fichier 'toto' 

2.6criture de 30000 octets a 1' offset 30 dans le fichier 
toto 

3. ecriture de 20000 octets a 1' offset 20 dans le fichier 
30 toto 

4. fermeture du fichier 'toto' 
Le log CFOR resultant sera: 
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•fichier toto^ 20 ? 30030 

Au moment de la copie (dump) , les donnees structurelles 
(metadata) ainsi que le contenu des modifications sont 
enregistres dans un fichier separe. 
5 Ce fichier separe est transmis sur le nceud stand-by et 

son exploitation permet de synchroniser 1' arborescence de 
maniere k ce qu'elle soit strictement identique k celle du 
ncBud operationnel au moment du dump. 

On va maintenant decrire le mecanisme de synchronisation 
10 mis en ceuvre dans le proced6 de replication selon 
1' invention. 

Lors de 1' apparition d'une machine SB, il faut 
synchroniser son systeme de fichiers (FS) par rapport a celui 
du ncEud operationnel OP. Cette synchronisation doit se faire 

15 sans bloquer le noeud operationnel OP done elle se fait sur un 
systeme de fichiers en constante evolution. Afin d'6viter le 
probl^me des images floues, la synchronisation se fait au 
t ravers d'un instantane (snapshot) du systeme de fichiers 
(file system) du noeud operationnel OP. La procedure est 

20 decomposee en 2 phases afin de limiter la taille du log de 
CFOR. 



1. Creation d'un instantan6 (snapshot) sur le noeud 
operationnel OP 
25 2.1ere synchro avec le noeud SB 

3. Destruction de 1' instantan6 (snapshot) sur le noeud 

operationnel OP 

4. Activation du log de CFOR et creation d'un. 2eme 

instantane (snapshot) sur le nceud operationnel OP 
30 5.2eme synchronisation avec le noeud SB (elle doit etre la 
plus courte possible) . 
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6. Suppression de 1' instantane (snapshot) sur le noeud 

operationnel OP, le noeud SB 6tant pr§t ^ recevoir un 

premiere copie (dump) tot ale. 
7.A la prochaine copie (dump), transfert du log de CFOR et 
5 mise a jour du systeme de fichiers FS du noeud SB avec les 

donnees de CFOR 
8,le cycle normal des copie/restauration (dump/restore) est 

en place. 

La recopie de la m6moire d'un processus se fait en 
10 analysant dynamiquement 1* organisation memoire interne du 
processus et en isolant les differentes zones : 

- texte 

- donnees 

- pile d' execution 

15 L' analyse de la memoire est effectuee sans intrusion 

dans le code utilisateur en s ' appuyant sur les donnees 
fournies par le systeme d' exploitation (Operating System). 
Ces donnees sont captur6es et analys6es dans le contexte m§me 
du processus et permettent de cr6er la table des zones 
20 m^moires utilis6es. 

Une fois 1' analyse termin6e, les agents d* interposition 
des appels . systeme d' allocation/liberation m6moire assurent 
le suivi de 1' Evolution de la table des zones m6moires. 

Lors de la copie (dump) , seules les zones memoire 
25 modifiables, c'est k dire accessibles en 6criture sont 
transferees sur le noeud stand-by ou elles seront recopi6es. 
Ainsi le processus sur le noeud stand-by contient les memes 
zones m6moires avec les memes donnees que sur le noeud 
operationnel • 

30 La sauvegarde du contenu de la memoire devant etre 

atomique du point de vue d'un processus, elle doit se faire 
sans que le processus ne puisse en changer I'etat, done 
processus bloqu6. Afin de ne pas bloquer le processus trop 
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longtemps, on s'appuie sur le mecanisme de « Copy On Write » 
du syst^me d' exploitation (primitive (fork) par exemple) pour 
cr6er une copie de 1' image m§moire du processus et on 
trans fert cette image vers les noeuds stand-by. One fois le 
5. transfert terminer 1' image m^moire maintenue par les 
m6canismes de « Copy On Write » est supprimfee. 

Le procede de replication selon 1' invention met aussi en 
ODUvre un mecanisme de copie (dump) incr6mentale qui s'appuie 
sur 1' analyse m^moire^ mais ajoute en plus un mecanisme de 
10 protection des pages en 6criture. 

Une fois 1' analyse des pages effectuee,. toutes les pages 
accessibles en ecriture sont protegees, c'est a dire qu'une 
§criture dans une de ces pages d^clenche 1* emission d'un 
signal de violation de protection de pages. 
15 *^ La protection s ' appuie sur les mecanismes fournis par le 
systeme d' exploitation tel que I'appel systeme « mprotect ». 

Lorsque 1' application tente de modifier une donnee^ la 
ou les pages contenant cette donn6e sont marquees comme 
modifi6es et deprot6g6es. Le deroulement du code applicatif 
20 n'est pas impacte par I'adjonction de ces m6canismes (non 
intrusivite) . 

Lors d'une copie (dump) incrementale, seules les pages 
modifi^es depuis le precedent dump sont transf6r6es. La copie 
(dump) termin6e, toutes les pages modifi6es sont re-proteg6es 
25 afin de d6tecter les prochaines ecritures. La copie (dump) 
incrfementale permet de r^duire la taille des donnees a 
transferer vers le stand-by k chaque copie (dump) . 

La gestion de$ declenchements des points de reprise peut 
etre effectuee a partir de la base MIB qui regoit, du noeud 
30 primaire ou operationnel, des informations sur les etats du 
systeme et de 1^ application, des informations sur les 
evenements et call-back sur 1' application et des informations 
delivrees par un analyseur d'6tat synthetique, corome 
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1' illustre la figure 7. L' organisation du basculeinent de 
1' application du noeud primaire vers un noeud secondaire agit 
par exemple sur un dernier point de reprise EVENT, un dernier 
point de reprise PERIODIC, un enregistrement (logging) 
d' entree, et peut inclure : 

- le choix d'un scenario de basculement, 

- le choix d'un point de reprise, 

- le declenchement de la restauration, 

- le declenchement (ou non) du re-jeu du Log 

- la notification du nouveau noeud operationnel . 

Bien siir, 1* invention n'est pas limitfee aux exemples qui 
viennent d'etre d6crits et de nombreux am^nagements peuvent 
etre apportes a ces exemples sans sortir du cadre de 
1 • invention . 
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REVENDICATIONS 



1. Procede pour repliquer une application logicielle dans une 
5 architecture multi-ordinateurs (cluster) , ladite application 
logicielle 6tant pr6alablement ex6cutee sur un premier 
ordinateur dudit cluster constituant un noeud primaire et 
etant destin^e k §tre r6pliquee sur au moins un autre 
ordinateur dudit cluster constituant un nceud secondaire, 
10 comprenant une replication des ressources associees k ladite 
application logicielle^ caract6ris6 en ce qu'il comprend une 
mise a jour au fil de I'eau desdites ressources repliquees 
par un mecanisme d' introspection dynamique prevu pour fourni 
la structure de 1 ' application a repliquer^ et un graphe 
15 dynamicjue des ressources et dependances mises en oeuvre^ 

2. Procede de replication selon la revendication 1, 
caracterise en ce qu'il comprend en outre une creation et une 
maintenance d'un arbre de d6pendance, qui fournit a chaque 

20 instant des inf ojcmations sur les ressources qu'il est 
necessaire de repliquer. 

3. Proced6 de replication selon I'une des revendications 1 ou 
2r caract6ris6 en ce qu'il comprend en outre un m6canisme de 

25 generation de point de reprise (« checkpointing ») , par 
lequel les ressources ^ rfepliquer sont rfepliqu^es sur un ou 
plusieurs noeuds secondaires. 

4. Precede de replication selon la revendication 3, 
30 caracterise en ce qu'il comprend trois etapes : 

- capture des ressources sur le noeud primaire. 
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- transfert par le r6seau vers uri ou plusieurs nitBuds 

secondaires/ et 

- restauration sur le ou les nceuds secondaires, 

5 5. Precede de replication selon I'une quelconque des 
revendications prec6dentes, caracteris6 en ce que les 
ressources r6pliqu6es incluent : 

- la memoire virtuelle de chaque processus concerne 
ainsi que sa pile d'appel,r 

10 - des ressources systemes (inter process communication ^ 

connexion reseau, etc.)/ et 

- des donnees ecrites sur disques, 

6.. Precede de replication selon I'une quelconque des 
15 revendications pr6cedentes et la revendication 3^ caracteris6 
en ce qu'il comprend en outre un mecanisme d' optimisation du 
m6canisme de generation de point de reprise* 

7. Precede de replication selon la revendication 6, 
20 caracterise en ce que le mecanisme de « checkpointing » est 

incremental . 

8. Precede de replication selon I'une des revendications 6 ou 
1, caracterise en ce que le mecanisme de « checkpointing » 

25 est discriminant. 

9. Precede de replication selon I'une des revendications 6 a 
8, caracterise en ce que le mecanisme de << checkpointing » 
inclut au moins I'une des fonctions suivantes : 

30 - une barriere de synchronisation de processus (PSB), 



- une gestion de ressources (RM) r 

- une gestion de ressources systeme (SRM),et 
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- une gestion de ressources de processus (PRM) . 

10. Proced§ de replication selon I'une quelconque des 
revendications pr6c6dentes, caracterise en ce qu'il comprend 
en outre un mecanisme de replication de fichiers de donnees 
applicatives entre un noeud operationnel (OP) sur lequel 
1' application est execut6e et un noeud dit de stand-by (SB) • 

11 • Procede pour realiser une continuite de f onctionnement 
d'une application logicielle dans une architecture multi- 
ordinateurs (cluster) , cette application 6tant ex§cutee a un 
instant donn6 sur I'un des ordinateurs du cluster^ appele 
ncBud primaire ou operationnel, les autres ordinateurs dudit 
cluster etant appeles noeuds secondaireS/ ce procede mettant 
en oeuvre le procede de replication selon I'une quelconque des 
revendications pr6cedentes, 

caract6ris6 en ce qu'il comprend les etapes suivantes : 

- replication de 1' application sur au moins des noeuds 
secondaires, de fa?on a realiser au moins un clone de ladite 
application, 

- mise i jour au fil de I'eau dudit ou desdits clones, 

et 

en cas de detection d'une d6f alliance ou d'un 
ev6nement affectant ledit noeud operationnel, basculement de 
service vers I'un au moins desdits clones. 

12. Procede de continuite de f onctionnement selon la 
revendication 11, caracterise en ce que la replication de 
1' application est de nature holistique. 
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13. Precede de continuite de f onctionnement selon I'une 
revendication 11 ou 12, caracterise en ce qu'il comprend en 
outre une raise a jour des clones de 1' application, 

5 14 • Proc6d6 de continuite de f onctionnement selon I'une des 
revendications 11 ^ 13 , caract6rise en ce qu'il comprend en 
outre une supervision de l'6tat de ressources n6cessairement 
au f onctionnement de 1' application. 

10 15 • Proced6 de continuite de f onctionnement selon I'une des 
revendications 11 a 14, caracterise en ce qu'il comprend en 
outre, a la suite d'une detection d'une def alliance ou d'un 
evenement affectant le noeud operationnel, une etape pour 
elire, parmi des clones installes sur des noeuds secondaires, 

15 un clone pour etre substitue a 1 ' application initiale, le 
noeud sur lequel ledit clone elu est installe devenant le 
nouveau noeud op6rationnel . 

16, Proc6d6 de continuity de f onctionnement selon I'une des 
20 revendications 11 A 15 , caracterise en ce qu'il comprend en 
outre un enregistrement sur chaque clone de messages regus 
par le noeud primaire ou operationnel, ces messages 6tant 
r6inject6s dans le clone 61u nouvel opferationnel en cas de 
basculement . 

25 

17. Systeme multi-ordinateurs pr6vu pour ex6cuter sur au 
moins desdits ordinateurs au moins une application 
logicielle, impl6mentant le precede pour r6aliser une 
continuite de f onctionnement selon I'une quelconque des 

30 revendications 11 a 16. 

18. Application du precede de replication selon I'une 
quelconque des revendications 1 ^ 10, pour une optimisation 
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automatique de ressources inf ormatiques par partage de charge 
par repartition dynamique de processus. 

19. Application du precede de replication selon I'une 
5 quelconque des revendications 1 a 10, pour une maintenance 

non interruptive par relocation ^ la demande de processus au 
travers d'un reseau de ressources inf ormatiques. 

20. Application du procede de replication selon I'' une 
10 quelconque des revendications 1 a 10, pour une preservation 

de contexte applicatif dans des applications mobiles. 
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